Method and system for migrating xml schemas in application releases

ABSTRACT

A method and system for migrating Extensible Markup Language (XML) schemas between releases of a computing application. The method provides first and second versions of an XML document by the computing application, each version having a different schema. The first version is migrated to the second version using a migration step. The method uses a Dependency Injection Framework to abstract the characteristics of the at least one migration step. The method also transforms the first schema to the second schema, based on the abstracted characteristics of the at least one migration step, in such a way that the first version of the XML document is migrated into the second version of the XML document. The method migrates the first version into the second version in such a way that the second version can access application data from the first version.

BACKGROUND Field

The instant disclosure relates generally to computing applicationsinvolving Extensible Markup Language (XML) documents, and in particularto methods and systems for migrating XML schemas between releases ofcomputing applications.

Description of the Related Art

A markup language is a computer language designed for the processing,definition and presentation of text. A markup language specifies codefor formatting, both the layout and style, within a text file. The codeused to specify formatting and define elements within a document arecalled tags. A markup language is human-readable, rather than typicalcomputer language programming syntax. One of the two most popular markuplanguages is Extensible Markup Language (XML). XML is a markup languagethat defines a set of rules for encoding documents in a format that isboth human-readable and machine-readable.

XML provides a lightweight and strongly typed way to persist the dataand state of a computing application, i.e., to have the computingapplication data and the computing application state survive after theprocess with which they were created has ended. The schema (i.e., theorganization and structure) of an XML document may change betweenreleases of a computing application. If the schema of the XML documentchanges, then the current release of the computing application likelywill not be able to access the application data from a previous release,thereby creating an incompatibility between releases of the samecomputing application.

There is a need for a method and system for migrating XML schemasbetween releases of computing applications.

SUMMARY

Disclosed is a method and system for migrating Extensible MarkupLanguage (XML) schemas between releases of a computing application. Themethod includes providing a first version of an XML document by thecomputing application, in which the first version of the XML documenthas a first schema. The method also includes providing at least onesecond version of an XML document by the computing application, in whichthe second version of the XML document has a second schema that isdifferent than the first schema. The method also includes migrating thefirst version of the XML document to the second version of the XMLdocument using a migration step. The method also includes using aDependency Injection Framework to abstract the characteristics of the atleast one migration step. The method also includes transforming thefirst schema to the second schema, based on the abstractedcharacteristics of the at least one migration step, in such a way thatthe first version of the XML document is migrated into the secondversion of the XML document. The method migrates the first version ofthe XML document into the second version of the XML document in such away that the second version of the XML document can access applicationdata from the first version of the XML document.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1a and 1b are schematic views of example schema changes betweentwo releases of an Extensible Markup Language (XML) document;

FIG. 2 is a schematic view of the transformation of an XML documentusing Extensible Stylesheet Language Transformation (XSLT);

FIG. 3 is a schematic view of an XML Migration Manager, according to anembodiment;

FIG. 4 is a schematic view of a class diagram illustrating therelationship between the different objects that are used in FIG. 3,according to an embodiment;

FIG. 5 is a schematic view of an example migration path used by the XMLMigration Manager, according to an embodiment; and

FIG. 6 is a schematic view of a portion of an example migrationinvolving a later released Interim Correction (IC) using the XMLMigration Manager, according to an embodiment.

DETAILED DESCRIPTION

Various embodiments of the present invention will be described in detailwith reference to the drawings, wherein like reference numeralsrepresent like parts and assemblies throughout the several views.Reference to various embodiments does not limit the scope of theinvention, which is limited only by the scope of the claims attachedhereto. Additionally, any examples set forth in this specification arenot intended to be limiting, and merely set forth some of the manypossible embodiments for the claimed invention.

FIGS. 1a and 1b are schematic views of example schema changes betweentwo releases of an Extensible Markup Language (XML) document (or object)10, i.e., a document or object whose data is formatted in the XMLlanguage. For example, as discussed hereinabove, the schema of an XMLdocument may change between releases of an application. FIG. 1aillustrates a first version (e.g., release version 1.0) of the XMLdocument 10. FIG. 1b illustrates a second version (e.g., release version2.0) of the XML document 10.

The XML document 10 includes a number of lines of data 12 in XML format.A first highlighted portion or node 14 of the data 12 shown in FIG. 1aand a second highlighted portion or node 16 of the program data 12 shownin FIG. 1b note the changes that have occurred between the first version(e.g., release version 1.0) of the XML document 10 and the secondversion (e.g., release version 2.0) of the XML document 10. All of theremaining data 12 is the same in both the first version (e.g., releaseversion 1.0) of the XML document 10 and the second version (e.g.,release version 2.0) of the XML document 10.

Because of the changes made between the first version (e.g., releaseversion 1.0) of the XML document 10 and the second version (e.g.,release version 2.0) of the XML document 10, conventional data formatconversions or transformations become problematic. For example, usingconventional data format conversions or transformations, deserializingthe XML document 10 serialized from the first version (e.g., releaseversion 1.0) of the XML document 10 into the second version (e.g.,release version 2.0) of the XML document 10 will be unsuccessful.Serialization is a process by which the state of an object (e.g., an XMLdocument) is transformed or converted into a form (e.g., a serial dataformat or data stream) that can be readily transported. Once theserialized object has been transported, the serialized data stream isconverted back into its object form (i.e., deserialized). However,because of a mismatch between the representation of the data structuresof the two versions of the XML document 10, deserializing the XMLdocument 10 serialized from the first version (e.g., release version1.0) of the XML document 10 into the second version (e.g., releaseversion 2.0) of the XML document 10 using conventional data formatconversions or transformations will fail.

As will be discussed in greater detail hereinbelow, according to anembodiment, problems associated with the incompatibility of releases ofthe same XML document are overcome by abstracting a layer of interfacesof the XML schema migration and then using a Dependency InjectionFramework to manage or fulfill all of the dependencies that are neededfor the XML migration to be performed. According to an embodiment, theXML migration involves one or more migration steps that use anExtensible Stylesheet Language Transformation (XSLT) to convert thestructure of the XML document.

FIG. 2 is a schematic view 20 of the transformation of an XML documentby applying Extensible Stylesheet Language Transformation (XSLT), i.e.,using an XSLT document 24 and an XSLT processor 26. ExtensibleStylesheet Language Transformation is an XML-related technology thatprovides a way to automatically transform an XML document from oneformat or version to another format or version. As shown in FIG. 2, afirst version (e.g., release version 1.0) of an XML document (shown as asource XML document 22) and the XSLT document 24 are input to the XSLTprocessor 26, and the XSLT processor 26 generates a second version(e.g., release version 2.0) of the XML document (shown as a target XMLdocument 28).

The XSLT processor 26 contains a set of rules to transform the sourceXML document 22 into the target XML document 28. Using the XSLTprocessor 26, the pattern of the element (i.e., the structure of thesource XML document 22) is identified in the source XML document 22. TheXSLT processor 26 then applies an appropriate template from the XLSTdocument 24 to create the target XML document 28. As the target XMLdocument 28 is being generated, the XML elements/structure in the sourceXML document 22 are filtered and reordered, and an arbitrary structureis added.

FIG. 3 is a schematic view of an XML Migration Manager 30, according toan embodiment. The XML Migration Manager 30 includes a Migration StepContainer component 32 and a Migration Step Executor component 34. TheXML Migration Manager 30 also includes or works with a DependencyInjection Framework (DIF) 36. According to an embodiment, the XMLMigration Manager 30 works with a plurality of Migration Steps 38 (e.g.,Migration Step 1, Migration Step 2, Migration Step 3, Migration Step n).The Migration steps 38 are an abstraction of the migration processingunit(s) coupled between two adjacent versions of the XML document.

The XML Migration Manager 30 can be a standalone computing device,machine or system, or a group of standalone computing devices, machinesor systems. That is, one or more of the Migration Step Containercomponent 32, the Migration Step Executor component 34 and theDependency Injection Framework 36 can be a standalone computing device,machine or system, or a group of standalone computing devices, machinesor systems. Regardless of the particular configuration of the XMLMigration Manager 30, it should be understood that the relationshipbetween the Migration Step Container component 32, the Migration StepExecutor component 34 and the Dependency Injection Framework 36 is amachine-to-machine connection, and involves machine-to-machinecommunications, i.e., the exchange of data between machines.

Each of the Migration Steps 38 contains an XSLT script or program (e.g.,XSLT script 1, XSLT script 2, XSLT script 3, XSLT script n) to transformthe XML document from one version to the next version, and eachMigration Step 38 exports itself to the XML Migration Manager 30 via theDependency Injection Framework (DIF) 36. The XML Migration Manager 30 isthe core component that collects all of the Migration Steps 38, and thenprocesses the migration.

Dependency Injection is a design pattern (i.e., a general, reusabletemplate or approach) that decouples dependencies between a first objectand a second object that is dependent on the first object. A dependencyis a reliance of one data document, application or object on anotherdata document, application or object. By decoupling dependencies betweena first object and a second dependent object, Dependency Injectionallows changes to be made to the first object without requiring changesto be made to the dependent second object just because changes wereneeded to the first object.

According to an embodiment, the Dependency Injection Framework 36 usesDependency Injection principles to manage, e.g., remove, thedependencies between the XML Migration Manager 30 and the MigrationSteps 38 so that the XML Migration Manager 30 does not need to know theMigration Steps 38 beforehand. Conventionally, when an applicationdesigns an XML document migration mechanism, the application must knowhow the XML schema within the XML document will be changed in futurereleases of the XML document. However, according to an embodiment, byhaving the Dependency Injection Framework 36 manage the dependenciesbetween the XML Migration Manager 30 and the Migration Steps 38 usingDependency Injection, the XML Manager 30 manages the information foreach migration in a future release of the XML document without needingto know the XML schema beforehand. This is possible by using an abstractlayer to abstract all of the characteristics of the migration (i.e., thecurrent/source XML version, the target XML version and the XSLT documentused to perform the XML transformation), so that when a new migration isexecuted, the only thing needed is to instruct the XSLT processor 26 howto convert the XML document.

As discussed hereinabove, the XML Migration Manager 30 has two corecomponents: the Migration Step Container component 32 and the MigrationStep Executor component 34. The Migration Step Container component 32stores all of the migration steps that are collected by the DependencyInjection Framework 36. The Migration Step Container component 32 alsodetermines a migration path from the first or begin version of the XMLdocument to the last or end version of the XML document.

The Migration Step Executor component 34 communicates with the MigrationStep Container component 32 to fetch the migration path. The MigrationStep Executor component 34 then executes the migration pathstep-by-step. As the Migration Step Executor component 34 executes eachmigration step, the Migration Step Executor component 34 uses the XSLTprocessor 26 (FIG. 2) to transform the XML document from one version tothe next version.

The Migration Step Container component 32 and the Migration StepExecutor component 34 depend on a set of Interfaces (shown in FIG. 4),which abstract all of the logic associated with the migration.Meanwhile, all of the migration steps also inherit the properties andmethods from the same set of interfaces and provide concrete migrationlogic. Therefore, although the XML Migration Manager 30 does not haveany knowledge about the concrete migration steps, the XML MigrationManager 30 can still execute the migration steps when an application isrunning.

FIG. 4 is a schematic view of a class diagram 50 illustrating therelationship between the different objects that are used in FIG. 3,according to an embodiment. Each of the Migration Steps 38 shown in FIG.3 (i.e., Migration Steps 1-N) are represented as XMLUpgrade Steps 39 inFIG. 4 (i.e., XMLUpgradeStep1, XMLUpgradeStep2, XMLUpgradeStepx). Also,an XMLUpgradeStep 41 is a base class that represents the upgrademigration step.

According to an embodiment, the migration method supports both theupgrade of an XML document (e.g., release version 1.0 of an XML documentto release version 2.0 of the XML document) as well as the downgrade ofan XML document (e.g., release version 2.0 of an XML document to releaseversion 1.0 of the XML document). An IXMLUpgradeStep box 56 is aninterface that represents the upgrade migration step. AnIXMLDowngradeStep box 58 is an interface that represents the downgrademigration step. It should be understood that although only the upgrademigration step is shown in detail, both the upgrade migration step andthe downgrade migration step are similarly executed.

The Migration Step Container component 32 is a sub-component of the XMLMigration Manager 30, as discussed hereinabove. The Migration StepContainer component 32 declares its dependencies through the DependencyInjection Framework 36. The Migration Step Container component 32 thenfills in these dependencies with all of the migrations steps 38. Afterreceiving all of the migration steps 38, the Migration Step Containercomponent 32 stores the migration steps 38 into a dictionary forcalculating the migration path from one version of the XML document toanother version of the XML document.

Each migration step has two properties: a CurrentVersion 52 and aNextVersion 54. The CurrentVersion 52 is the version of the XML document10 on which the migration step is applied. The NextVersion 54 is theversion of the XML document 10 that is generated after executing themigration step. The CurrentVersion 52 and the NextVersion 54 areincluded within an IXMLMigrationStep 59, which is an interface thatrepresents an abstraction of the migration step, which can be either anupgrade migration step or a downgrade migration step. By abstracting theMigration Steps 38, the Dependency Injection Framework 36 (and thus theXML Migration Manager 30) is no longer dependent on the Migration Steps38. Instead, the Dependency Injection Framework 36 (and the XMLMigration Manager 30) becomes dependent on the IXMLMigrationStep 59, asdo the Migration Steps 38.

According to an embodiment, each migration step 38 performs similarly toa singly linked list, in which one step points to the next step. Whentwo versions of an XML document 10 are input into the Migration StepContainer component 32, the Migration Step Container component 32 isable to determine a migration path, which is a sequence of migrationsteps from the first or begin version of the XML document 10 to the lastor end version of the XML document.

FIG. 5 is a schematic view of an example migration path 70 used by theXML Migration Manager 30, according to an embodiment. The examplemigration path 70 is a migration path from an XML document version 2.1to an XML document version 3.0. As shown, the migration path 70 includesa first migration step 72 (i.e., Migration Step 1), in which the CurrentVersion is XML document version 2.1 and the Next Version is XML documentversion 2.2. The migration path 70 also includes a second migration step74 (i.e., Migration Step 2), in which the Current Version is XMLdocument version 2.2 and the Next Version is XML document version 2.3.The migration path 70 also includes a third migration step 76 (i.e.,Migration Step 3), in which the Current Version is XML document version2.3 and the Next Version is XML document version 2.4. The migration path70 also includes a fourth migration step 78 (i.e., Migration Step 4), inwhich the Current Version is XML document version 2.4 and the NextVersion is XML document version 3.0

As discussed hereinabove, the Migration Step Executor component 34 isanother sub-component of the XML Migration Manager 30. The mainresponsibility of the Migration Step Executor component 34 is to querythe Migration Step Container component 32 to retrieve the migrationpath. After retrieving the migration path, the Migration Step Executorcomponent 34 iterates through each migration step to execute its migratemethod, which uses the XSLT processor 26 (FIG. 2) to perform thetransformation. When the migration is completed, the Migration StepExecutor component 34 reports the migration status and/or any handleerrors.

One of the features of the Migration Manager 30 and its migration methodis greater extensibility (i.e., the ability to accommodate futuregrowth) compared to conventional migration methods. The improvedextensibility of the Migration Manager 30 and its migration method isthe result of several features. First, all of the migration stepsperformed by the Migration Manager 30 are pluggable in the MigrationManager 30 with the help of the Dependency Injection Framework 36, asshown in FIG. 3.

Second, the Migration Step Container component 32 and the Migration StepExecutor component 34 do not depend on any of the concrete migrationsteps. According to an embodiment, the Migration Step Containercomponent 32 and the Migration Step Executor component 34 apply theInversion of Control (loc) Principle. That is, the flow of control,i.e., the functions performed by the Migration Step Container component32 and the Migration Step Executor component 34 as part of the migrationmethod, is received from a generic framework, i.e., the DependencyInjection Framework 36. The use of the Inversion of Control (loc)Principle increases modularity of the migration method, and thus makesthe migration method more extensible.

Third, an XSLT script is embedded within each migration step. Theembedded XSLT script is processed by the XSLT processor 26 (FIG. 2). Byusing XLST technology, the XML Migration Manager 30 eliminates a lot ofduplicate source code for the XML document processing.

According to an embodiment, other features of the migration methoddescribed herein demonstrate improved extensibility compared toconventional migration methods. For example, the migration methoddescribed herein not only supports the upgrade of an XML document, butalso supports the downgrade of an XML document by providing downgrademigration steps. According to an embodiment, the downgrade migrationsteps are performed by the Migration Step Container component 32 and theMigration Step Executor component 34 in the same manner as the upgradesteps are performed.

Also, the migration method described herein reduces the effort involvedin modifying the source code for a migration between chronologicalreleases. According to an embodiment, only one new migration step isadded, but no other modifications are required to the migration method.

Also, the migration method described herein reduces the effort involvedin delivering a patch for a migration from an Interim Correction (IC)released later to a higher version, which is released earlier. FIG. 6 isa schematic view of a portion of an example migration 80 using the XMLMigration Manager 30, according to an embodiment, in which an InterimCorrection (IC) is released later than the earlier released higherversion. The example migration path 80 is a migration path from an XMLdocument version 2.3 to an XML document version 3.1. As shown, themigration path 80 includes a migration step 82 (i.e., Migration Step 3),in which the Current Version is XML document version 2.3 and the NextVersion is XML document version 2.4. The migration path 80 also includesanother migration step 84 (i.e., Migration Step 4), in which the CurrentVersion is XML document version 2.4 and the Next Version is XML documentversion 3.0. The migration path 70 also includes another migration step86 (i.e., Migration Step 5), in which the Current Version is XMLdocument version 3.0 and the Next Version is XML document version 3.1.

However, according to an embodiment, if an Interim Correction (IC) islater released, the migration path 80 includes a new migration step 88,89 (i.e., Migration Step 4a and Migration Step 4b) as a patch. In thenew migration step 88, the Current Version is XML document version 2.4and the Next Version is XML document version 2.5 (IC), and in the newmigration step 89, the Current Version is XML document version 2.5 (IC)and the Next Version is XML document version 3.0.

According to an embodiment, the migration method described herein can beused to migrate other data, with relatively little modification to themigration method. For example, for database migration, the XSLT scriptis replaced with a Structured Query Language (SQL) script.

It will be apparent to those skilled in the art that many changes andsubstitutions can be made to the embodiments described herein withoutdeparting from the spirit and scope of the disclosure as defined by theappended claims and their full scope of equivalents.

1. A method for migrating Extensible Markup Language (XML) schemasbetween releases of a computing application, the method comprising:providing a first version of an XML document by the computingapplication, the first version of the XML document having a firstschema; and providing at least one second version of an XML document bythe computing application, the second version of the XML document havinga second schema, wherein the second schema is different than the firstschema; migrating the first version of the XML document to the secondversion of the XML document using at least one migration step; using aDependency Injection Framework to abstract the characteristics of the atleast one migration step; and transforming the first schema to thesecond schema, based on the abstracted characteristics of the at leastone migration step, in such a way that the first version of the XMLdocument is migrated into the second version of the XML document,wherein the first version of the XML document is migrated into thesecond version of the XML document in such a way that the second versionof the XML document can access application data from the first versionof the XML document.
 2. The method as recited in claim 1, whereinmigrating the first version of the XML document into a second version ofthe XML document uses an Extensible Stylesheet Language Transformation(XSLT) to convert the structure of the XML document from the firstversion of the XML document to the second version of the XML document.3. The method as recited in claim 1, wherein migrating the first versionof the XML document into a second version of the XML document comprises:inputting the first version of the XML document into an ExtensibleStylesheet Language Transformation (XSLT) processor, inputting an XSLTdocument into the XSLT processor, and applying Extensible StylesheetLanguage Transformation by the XSLT processor to generate the secondversion of the XML document.
 4. The method as recited in claim 3,wherein the XSLT processor: identifies the structure of the firstversion of the XML document, and applies a template from the XSLTdocument to generate the second version of the XML document.
 5. Themethod as recited in claim 3, wherein the XSLT processor: filters thestructure of the first version of the XML document, reorders thestructure of the first version of the XML document, and adds anarbitrary structure to the first version of the XML document.
 6. Themethod as recited in claim 3, wherein the characteristics of the atleast one migration step include the first version of the XML document,the second version of the XML document, and the XSLT document.
 7. Themethod as recited in claim 1, wherein the Dependency Injection Frameworkremoves all dependencies between the at least one migration step and theapplication performing the migration of the first version of the XMLdocument to the second version of the XML document.
 8. The method asrecited in claim 6, wherein the first version of the XML document ismigrated to the second version of the XML document without theapplication performing the migration being dependent on the at least onemigration step.
 9. The method as recited in claim 1, wherein the firstversion of the XML document is released before the second version of theXML document, and wherein migrating the first version of the XMLdocument to the second version of the XML document comprises an upgrademigration step.
 10. The method as recited in claim 1, wherein the secondversion of the XML document is released before the first version of theXML document, and wherein migrating the first version of the XMLdocument to the second version of the XML document comprises a downgrademigration step.
 11. An Extensible Markup Language (XML) migrationmanager system for migrating schemas between releases of a computingapplication, the XML migration manager system comprising: a migrationstep executor; a migration step container coupled to the migration stepexecutor; and a Dependent Injection Framework coupled to the migrationstep container, wherein the Dependent Injection Framework collects atleast one migration step for migrating a first version of an XMLdocument by the computing application to a second version of an XMLdocument by the computing application, wherein the first version of theXML document has a first schema, wherein the second version of the XMLdocument has a second schema, and wherein the second schema is differentthan the first schema, wherein the migration step container collects theat least one migration step from the Dependent Injection Framework andstores the at least one migration step within the migration stepcontainer, wherein the Dependent Injection Framework removes anydependencies between the migration manager system and the at least onemigration step by abstracting the characteristics of the at least onemigration step, wherein the migration step container determines amigration path based on the first version of the XML document and thesecond version of the XML document, wherein the migration step executorfetches the migration path from the migration step container, whereinthe migration step executor transforms the first schema to the secondschema, based on the abstracted characteristics of the at least onemigration step, in such a way that the first version of the XML documentis migrated into the second version of the XML document, and wherein thefirst version of the XML document is migrated into the second version ofthe XML document in such a way that the second version of the XMLdocument can access application data from the first version of the XMLdocument.
 12. The XML migration manager system as recited in claim 11,wherein the migration step executor uses an Extensible StylesheetLanguage Transformation (XSLT) processor to convert the structure of theXML document from the first version of the XML document to the secondversion of the XML document.
 13. The XML migration manager system asrecited in claim 11, wherein the migration step executor: inputs thefirst version of the XML document into an Extensible Stylesheet LanguageTransformation (XSLT) processor, and inputs an XSLT document into theXSLT processor, and wherein the XSLT processor applies ExtensibleStylesheet Language Transformation to generate the second version of theXML document.
 14. The XML migration manager system as recited in claim13, wherein the XSLT processor: identifies the structure of the firstversion of the XML document, and applies a template from the XSLTdocument to generate the second version of the XML document.
 15. The XMLmigration manager system as recited in claim 13, wherein the XSLTprocessor: filters the structure of the first version of the XMLdocument, reorders the structure of the first version of the XMLdocument, and adds an arbitrary structure to the first version of theXML document.
 16. The XML migration manager system as recited in claim13, wherein the characteristics of the at least one migration stepinclude the first version of the XML document, the second version of theXML document, and the XSLT document.
 17. The XML migration managersystem as recited in claim 11, wherein the first version of the XMLdocument is released before the second version of the XML document, andwherein migrating the first version of the XML document to the secondversion of the XML document comprises an upgrade migration step.
 18. TheXML migration manager system as recited in claim 11, wherein the secondversion of the XML document is released before the first version of theXML document, and wherein migrating the first version of the XMLdocument to the second version of the XML document comprises a downgrademigration step.